1. Field of the Invention
The present invention relates generally to managing and displaying casework data, and in particular, to a computer-implemented method, apparatus, and computer readable storage medium for encapsulating diverse user interface components while consistently enforcing external metadata and constraints for the components. In addition, the present invention relates to the field of case management in which data is collected from one or more users according to a pattern orchestrated by a case solution.
2. Description of the Related Art
An industry solution is an information technology (IT) asset that helps solve an industry-specific problem and is easily reconfigurable to meet specific needs of each client. A solution often helps a client to reach out to and interact with their own customers or users.
An important segment within industry solutions is called case management, which takes the view that a customer/user interaction pattern can be orchestrated by a case. The definition of a case includes data structure and data type definitions, metadata and validation constraint definitions, business process and user access rules, and other possible resources. Each piece of data in a case is called a case property, which consists of a name and a value. A case property can be part of the information collected for a case, and it may also be used in decision logic of business process rules. Metadata for a case property can include information about the case property such as whether it is read-only or hidden. A validation constraint may be as simple as requiring the case property value to be a particular data type, such as a number, or it could be a range constraint, such as an upper or lower numeric bound, on the case property value.
Based on an initial request by a customer or user, the case management system instantiates the case definition, and the resultant case orchestrates the interaction to achieve the goal or goals implicit in the defined pattern. For example, a case management system could be used to orchestrate the means by which a customer makes and successfully completes a warranty claim for a defective product. The process would begin with collecting initial information about the defective product, about the defect, and about the purchase. The process would include determining the legitimacy of the warranty claim, providing basic support to qualify the defect and determine a course of action, and ultimately to effect a repair or replacement of the product.
A case management user interface is a collection of interactive components that collect data from a user and store it in the data structure of a case (an instance of a case definition). The presentation of the user interface is also affected by the metadata of the case. A common piece of metadata is an enumeration of the valid values that a data item may take. If such a list is available, then it would be presented in a dropdown menu or list box, and the input would be collected via list selection rather than by free-form typing in a text entry field. Other common metadata includes Boolean flags such as for indicating whether a data node is read-only or required to fill in a step of the case processing. The user interface components would be affected by enforcing the read-only property or providing a sensory indication of the required property. Still other metadata can define validity constraints, such as a numeric data type or a minimum or maximum value or length. The user interface of a component associated with a data node would be affected by indicating whether the current data value is or is not valid according to the constraints. A case management asset would also typically forbid progress to the next step of the orchestrated pattern when the data associated with the current step contains invalid values.
The term “case management solution” has been used to describe a software solution that supports the design, deployment, execution and reconfiguration of case management assets. As the field of case management matures, the term “advanced case management” has emerged as a way to characterize case management assets that have advanced feature requirements, such as the requirement to collect many dozens, scores or hundreds of fields of data. Some examples of advanced case management include: home or car insurance claims, credit card charge dispute resolution, citizen-facing ombudsperson cases, contagious disease outbreak tracking, and management of complex medical or psychological treatment cases. IBM Case Manager™ (ICM) is one product entry in the field of advanced case management solutions.
A problem arises in advanced case management solutions with respect to the expected maturity of the user interface. The typical case management solution generates a user interface presentation layer (herein called a Case Data widget) for the data of a step using a simple linear columnar approach or a column of expandable stacks of related data values. The advantage of this approach is that it most easily adapts to a reconfiguration of the case management asset in which the data structure is amended to add or remove data nodes.
However, there are a number of disadvantages to this approach. For one, it provides a one-size-fits-all approach to the user interface layout in which usability substantially degrades in quality as the size of the data set grows. As well, larger data sets tend to correlate to more advanced requirements in an overall solution that a case management asset simply cannot begin to address using only a simple user interface approach.
Accordingly, a critical feature in the user interface is the ability to display and interact with data fields representing case properties or tasks. A variety of configurable field layout widgets is desired, where the designer of an end solution can select an appropriate tool for each user interface page based on the complexity of the interface (number of fields, interactions between fields, and so on), the complexity of external interactions (events between components, interactions with databases, interactions between field, etc.), and the flexibility needed in expressing the user interface including internal constraints (e.g., the number of fields, interactions between fields, layout of fields, ordering, dynamic elements, etc.).
A form is a kind of interactive document that combines a data structure with a template describing interaction behavior rules and a comprehensive user interface definition. The document processor of a form is a software system that an end-user interacts with via the defined user interface and according to behavioral rules. Data from the end-user is collected with the user interface and stored in the data structure of the form.
Forms documents focus on structured data collection. Examples include FileNet P8 eForms, IBM Forms, and PDF Forms. Other examples of interactive documents are spreadsheets and word processing documents, in proprietary formats or ODF (open document format). These documents can collect data in the context of “unstructured” content, such as fill-in-the-blanks components within the free-flowing text of a textual contract, or semi-structured content, such as spreadsheets that combine explanatory text cells with data input and calculations needed for expense reports or sales projections.
In a prior release of an advanced case management solution, one version of a forms technology was incorporated into the case definition facility. The solution was the IBM Case Manager, and the forms technology was FileNet P8 eForms. By including a P8 eForm in the case management assets, it became possible to present a reasonably high-precision user interface layout for data collection, as an alternative to the default simple user interface approach.
However, a disadvantage of this approach is that a number of advanced requirements could not be met using only the one interactive document technology because no single technology is intended to provide all the interactive document features that may be needed across the wide range of solutions that fit the general case management pattern.
In the above mentioned incorporation of a forms technology into an advanced case management solution, a second disadvantage was that the focus of the incorporation was on providing an alternative means of defining the user interface layout. However, the metadata components of the case management asset were not accommodated, leading to duplication of interaction behavior rules in order to ensure consistent behavior between the form interface and the simple data user interface.
In view of the above, there are two primary problems in the prior art. First is the development of a user interface abstraction that allows many diverse user interface tools to be applied. Second is a mechanism for consistently enforcing system behaviors that are expressed in the very complex environment that surrounds and backs the user interface. An important aspect of this is enforcing system constraints, such as allowed ranges, choice lists, and so on, where the user interface tools may or may not support the full set of system constraints.
Existing solutions are generally purpose built, and are limited by system capabilities and the time available to build new components. For example, in ICM 5.0™ (available from the assignee of the present invention), a simple field layout widget was provided. This Case Data widget provides a good expression of the system constraints since it was designed with the overall ICM system in mind. However, the widget is very limited in its ability to interact with other systems or to provide a more customized user interface.